Proposes two new system APIs for the prospective threshold key derivation (vetKD) feature in the management canister.

Notes

• The API is designed so that it allows for implementing the scheme referred to as An aggregatable vetBLS scheme (2) in the related talk at the Real World Crypto Symposium (RWC) 2023.
• The APIs are designed to be similar to the ones for threshold ECDSA.
• Information regarding usage of vetKD keys is not included in the interface spec on purpose. The idea is that the relevant information will later be provided in the Internet Computer Developer Docs.

Alternatives considered

We considered the following alternative API, where one would have two sets of API pairs: one pair for threshold key derivation, and a second one for threshold BLS signatures.

  // Threshold key derivation
  vetkd_public_key : (record {
    canister_id : opt canister_id;
    key_id : record { curve : vetkd_curve; name : text };
  }) -> (record { public_key : blob; });
  vetkd_encrypted_key : (record {
    derivation_id : blob;
    key_id : record { curve : vetkd_curve; name : text };
    encryption_public_key : blob;
  }) -> (record { encrypted_key : blob; });

  // Threshold BLS signature
  bls_public_key : (record {
    canister_id : opt canister_id;
    derivation_path : vec blob;
    key_id : record { curve : vetkd_curve; name : text };
  }) -> (record { public_key : blob; });
  sign_with_bls : (record {
    message : blob;
    derivation_path : vec blob;
    key_id : record { curve : vetkd_curve; name : text };
  }) -> (record { signature : blob; });

This alternative was discarded, however, because there is a concern that not all possible future use cases can be covered with this split API approach.

TODOs

• Determine if we should specify further constraints on input data (e.g., max size of derivation_id, etc.)